In the process of software development, automation testing is an important and critical step in the testing cycle. Testing is necessary to ensure quality in the software. For present day automation testing tools, part of the testing cycle includes graphical user interface (GUI) object testing. GUI objects include icons, push buttons, drop down menus, etc. that a user of the program will use to interact with the software. GUI object testing is typically implemented via a record and playback approach, where interactions with GUI objects are recorded and then played back. Interactions include, for example, clicking on links, buttons, etc. and entering data into entry fields, check boxes, etc. The test tool records these user actions, together with a record of the individual GUI objects under test that were interacted with. The record and playback approach is an important feature of automation testing tools as it provides an easy way to create test scripts without requiring extensive knowledge of coding and development.
To achieve the ability to playback previously recorded user actions, these tools store the GUI object properties in an object map, or some other tool specific artifact. The object map can in turn be referenced when the tool executes the test script and replays the recorded actions. The GUI object properties contain information that the tool requires to uniquely identify GUI objects during script playback. Examples of such object properties include the object class, text, identifier, name, etc.
In one existing approach, every time one or more GUI's of the application user interface (UI) changes, the object map is modified to include the new object properties. For example, modification may be required when the application is migrated from an old version to new version, migrated from one language to another language, when there is a change in the technology of the application's UI, or when there is an application feature change or enhancement. However, with this approach, if the script is to be executed against an older version of the application UI, the changes to the object map will need to be rolled back. If the script is later to be executed against the current version, the changes would have to be reintegrated into the object map. Extra time and effort are required of the tester to maintain the scripts and update the object map every time, resulting in an increase of the overall cost of test execution.
An existing alternative approach is to use descriptive programming instead of using the object map, where a tester can directly call the tool application programming interfaces (API's) to find and modify the desired GUI objects. However, using descriptive programming requires time and special skills.
For example, assume there is an application under development for Company X, and test scripts have been created via the automation test tool to test the application UI. The textual information on a link object on the UI are Company X specific labels. When the same application is customized for Company Y, the same link object is to have Company Y specific labels. If the same scripts recorded to test the Company X customized application are to be used for the Company Y customized application, the properties of the link object has to be updated in the scripts. Once updated, this script can no longer be used to test the Company X customized application. The tester will have to maintain different versions of the script to test the same application.